Today, Mobile Network Operators (MNOs) typically employ WiFi only for offloading “best effort” Internet traffic from their cellular and core networks. However, increased interest in operator deployment of “small cells” and “Carrier WiFi” will encourage Mobile Network Operators (MNOs) to seek new standard/vendor solutions for better interoperability between local cellular and WiFi networks enabling more control over their subscribers' Quality of Experience (QoE).
Specifically, as operators adopt “Carrier WiFi” to optimize their networks and reduce Capital Expense (CapEx)/Operating Expense (OpEx) we expect greater deployment of “Trusted” WLAN Access Networks (TWAN 102) that can directly interface with an operator's Mobile Core Network (MCN). We also expect greater integration of MNO deployed small cell and WiFi access networks within common geographical areas such as high-traffic urban metropolitan hotspot locations.
The GPRS Tunneling Protocol (GTP) [GPRS standing for General Packet Radio Service] has been the standard protocol for packet data transport in 3rd Generation Partnership Project (3GPP) networks. In terms of inter-working with different types of non-3GPP networks (e.g., Wireless Local Area Networks (WLAN), Worldwide Interoperability for Microwave Access (WiMAX), CDMA2000), the Internet Engineering Task Force (IETF) Proxy Mobile IP (PMIP) protocol has also been standardized as a general solution. However, for WLAN access networks in particular, 3GPP has also standardized use of their native GTP protocol as described below.
The 3GPP Release 11 SA2 work item for “52a Mobility based on GTP & WLAN access to EPC 106” (SaMOG) focused on enabling a GTP-based S2a interface for “Trusted WLAN Access Networks” (TWANs) 102 toward the PDN Gateway (PGW) 112. The Release 11 scope precluded any solutions that would impact the UE and the overall results were captured in TR 23.852. The Release 11 architectures, functional descriptions and procedures were subsequently standardized in section 16 of TS 23.402. The applicable GTP control plane protocol for tunnel management (GTPv2-C) is specified in TS 29.274, and the GTP user plane protocol (GTP-U) is specified in TS 29.281. SaMOG has been extended as a Release 12 work item to address several Release 11 limitations and will include TWAN 102 solutions for UE-initiated PDN connectivity, multi-PDN connectivity, and seamless inter-system handover.
3GPP Release 10 standardized a GTP-based S2b interface for Untrusted WLAN access to the EPC 106. Section 7 of TS 23.402 includes the associated support for a GTP-based S2b interface between an evolved Packet Data Gateway (ePDG) and the PGW 112. Untrusted WLAN solutions require UE support for IPSec as well as EPC 106 deployment of an ePDG for establishing IPSec security associations with each UE.
3GPP Release 6 provided a standardized WLAN Interworking (I-WLAN) solution by introducing a Packet Data Gateway (PDG) for WLAN access to the “pre-EPC” packet-switched core network. The standard architectures and procedures were captured in TS 22.234. Annex F of TS 23.234, also described how to re-use existing GGSN deployments to implement the PDG functionality using a subset of the Gn interface (denoted as Gn′) via a “Tunnel Termination Gateway” (TTG) using GTP towards the GGSN. Again, these solutions require UE support for IPSec as well as PDG/TTG support for establishing an IPSec tunnel with each UE.
The current architecture for non-roaming Trusted WLAN 102 and 3GPP LTE 104 access to EPC 106 is shown in FIG. 1.
Per section 16.1.1 of TS 23.402, when the WLAN is considered trusted by the operator, the Trusted WLAN Access Network (TWAN) 102 can be connected to the Evolved Packet Core (EPC) 106 via the STa interface toward the 3GPP AAA server/Proxy 118, and via the S2a interface toward the PDN Gateway (PGW) 112.
Comparing this to 3GPP LTE access, the LTE access network 104 (i.e. eNB or HeNB) is connected to the EPC 106 via the S1-MME interface toward the Mobility Management Entity (MME) 108, via the S1-U interface toward the Serving Gateway (SGW) 110, and indirectly via the S5 interface towards the PDN Gateway (PGW) 112.
An optional “Local Gateway” function (L-GW) 120 is also shown for small cell local IP access. We also show an optional HeNB Gateway (HeNB GW) 130 that may be used to concentrate the control plane signaling for multiple HeNBs toward the MME 108 and could also be used to handle HeNB user plane traffic toward the SGW 110. Finally, we show an optional Security Gateway (SeGW) 122 that may be used to provide secure access from the 3GPP LTE access network 104 (e.g. via HeNBs) to the EPC 106, i.e. via IPSec tunneling.
3GPP refers to an LTE femtocell as a Home eNodeB (HeNB). The HeNB is a type of cellular base station that is designed as “plug-and-play” customer premises equipment (CPE) that can be installed in residential and enterprise environments without the need for an experienced technician. HeNBs may also be deployed in public venues including hotspot locations. HeNBs use a broadband Internet connection to access a remote HeNB Management System (HeMS) for automatic configuration, while also providing backhaul access the EPC 106 network for cellular packet data services.
HeNBs operate in either closed, open or hybrid modes. Closed HeNBs only allow access to UEs that are part of an associated Closed Subscriber Group (CSG). Open HeNBs allow access to all subscribers. Hybrid HeNBs provide preferential treatment for associated CSG subscribers, while also allowing access to other subscribers based on resource availability (possibly with reduced QoS).
TS 23.402 considers the detailed functional split within a Trusted WLAN Access Network (TWAN) 102 as out of scope for 3GPP. Only the external behavior exposed by the SWw, S2a, and STa interfaces are in scope. Nevertheless, 3GPP did assume a reference TWAN 102 architecture for describing standard R11/R12 procedures related to S2a mobility over GTP (SaMOG). The architecture only describes the functional entities terminating each external interface and does not necessarily describe the processing between functional entities within the TWAN 102. The functions assumed to exist within the TWAN 102 are as described below.
WLAN Access Network (WLAN AN) includes of one or more WLAN Access Points (APs). An AP terminates the UE's WLAN IEEE 802.11 link via the SWw interface. The APs may be deployed as standalone APs or as “thin” APs connected to a Wireless LAN Controller (WLC), e.g., using the IETF CAPWAP protocols.
Trusted WLAN Access Gateway (TWAG) 124 terminates the GTP-based S2a interface with the PGW 112 and may act as the default IP router for the UE 105 on its WLAN access link. It also may act as a DHCP server for the UE. The TWAG 124 typically maintains UE 105 and AP MAC address associations for forwarding packets between the UE 105 (via the WLAN AP) and the associated S2a GTP-U tunnel (via the PGW 112).
Trusted WLAN AAA Proxy (TWAP) 126 terminates the Diameter-based STa interface with the 3GPP AAA server 118. It relays the AAA information between the WLAN AN and the 3GPP AAA server (or Proxy in case of roaming) 118. It can inform the TWAG 124 of layer 2 attach and detach events. It establishes the binding of UE subscription data with UE MAC address and can provide such information to the TWAG 124.
TWAN 102 can provide Authentication and Security. It is assumed that the UE can leverage USIM features for both 3GPP (LTE) and non-3GPP (WLAN) access. From Section 4.9.1 of TS 23.402:                “Non-3GPP access authentication [e.g., via WLAN] defines the process that is used for Access Control, i.e., to permit or deny a subscriber to attach to and use the resources of a non-3GPP IP access which is interworked with the EPC network. Non-3GPP access authentication signaling is executed between the UE and the 3GPP AAA server/HSS.        Trusted 3GPP-based access authentication is executed across an STa reference point. The 3GPP based access authentication signaling shall be based on IETF protocols, e.g., Extensible Authentication Protocol (EAP) as specified in RFC 3748.”        
The STa interface and Diameter application are used for authenticating and authorizing the UE 105 for EPC 106 access via trusted non-3GPP accesses. 3GPP TS 29.273 0 describes the standard TWAN 102 procedures currently supported on the STa interface.
TWAN 102 can provide IP Address Allocation. For EPC 106 access via GTP-based TWAN 102, the IPv4 address and/or IPv6 prefix is allocated to the UE 105 when a new Packet Data Network (PDN) connection is established with the EPC 106 over TWAN 102. A separate IP address may also be allocated by the TWAN 102 for local network traffic and/or direct Internet offload.
For PDN connectivity through EPC 106 via TWAN 102, the TWAN 102 receives the relevant PDN information via EAP/Diameter or WLCP signaling. The TWAN 102 may then request a routable IPv4 address for the UE 105 from the PGW 112 via the GTP Create Session Request. The IPv4 address is then delivered to the TWAN 102 during the GTP tunnel establishment via the GTP Create Session Response. If the UE 105 requests an IPv4 address for PDN connectivity via DHCPv4, the TWAN 102 delivers the received IPv4 address to the UE 105 within DHCPv4 signaling. Corresponding procedures are also defined for IPv6.
For 3GPP LTE access, the UE 107 automatically triggers a default PDN connection as part of its initial attachment to the EPC 106 network. It may also subsequently establish additional PDN connections as needed.
The primary purpose of the Attach procedure is for the UE 107 to register with the network in order to receive services for which it has subscribed to. The Attach procedure confirms the user's identity, identifies the services it is allowed to receive, establishes the security parameters (e.g., for data encryption), and notifies the network of the UE's initial location (e.g., in case it needs to be paged). Also, to support the “always-on” network connectivity expected by today's users, the LTE standards specify establishment of a default PDN connection as part of the Attach procedure. The radio resources for this default connection may be released during periods of inactivity, however the rest of the connection remains intact and the end-to-end connection can be quickly re-established by reassigning the radio resources in response to UE service requests.
When a UE 107 attempts to attach to the EPC 106 via an (H)eNB, it first establishes a Radio Resource Control (RRC) connection with the (H)eNB and encapsulates the Attach Request within the RRC signaling. The (H)eNB then selects an MME 108 and forwards the Attach Request within S1-AP signaling on the S1-MME interface. The MME 108 retrieves subscription information from the HSS 116 via the S6a interface in order to authenticate the UE 107 and allow attachment to the EPC 106.
After successfully authenticating the UE 107, the MME 108 selects an SGW 110 (e.g., based on proximity to the (H)eNB), and also selects a PGW 112, e.g., based on the default Access Point Name (APN) retrieved from HSS 116 or a specific APN requested by UE. The MME 108 communicates with the SGW 110 over the S11 interface to request creation of the PDN connection. The SGW 110 then executes the signaling to establish a GTP user plane tunnel with the designated PGW 112 over the S5 interface.
“GTP control” signaling also takes place indirectly within the S1-AP protocol between the MME 108 and (H)eNB. This ultimately leads to the establishment of a GTP user plane tunnel on the S1-U interface between (H)eNB and SGW 110.
The end-to-end path for the PDN connection between the UE 107 and PGW 112 is thus completed through the (H)eNB and SGW 110.
For non-3GPP TWAN 102 access, UE authentication and service authorization is accomplished via Extensible Authentication Protocol (EAP) signaling between the UE and 3GPP AAA server 118.
The PDN connectivity service is subsequently provided by the point-to-point connectivity between the UE 105 and the TWAN 102, concatenated with S2a bearer(s) between the TWAN 102 and the PGW 112. Unlike the LTE model, the WLAN radio resources are “always-on” from an EPC 106 perspective, e.g. any power-saving optimizations are handled transparently using IEEE 802.11 procedures within the WLAN.
When a UE 105 attempts to connect to the EPC 106 via a TWAN 102, it first establishes a Layer 2 connection with the WLAN and encapsulates EAP messages within EAP over LAN (EAPoL) signaling. The WLAN forwards the EAP messages to a TWAP 126 that then encapsulates them within Diameter signaling towards the 3GPP AAA server 118 via the STa interface. The 3GPP AAA server 118 retrieves subscription information from the HSS 116 via the SWx interface in order to authenticate the UE 105 and allow attachment to the EPC 106.
Beginning with 3GPP Release 11, the 3GPP AAA server 118 is able to provide the TWAN 102 with information via STa for establishing a PDN connection to the default PDN provisioned in the HSS 116. The TWAN 102 then exercises GTP control plane (GTPv2-C) and user plane (GTP-U) protocols over the S2a interface directly toward the PGW 112, thereby completing the PDN connection between the UE 105 and PGW 112 through the TWAN 102.
For 3GPP Release 12, the SaMOG phase-2 work item defined additional procedures for UE-initiated PDN connectivity, multi-PDN connectivity, and seamless inter-system handover.
For the case of single-PDN capable TWAN 102 scenarios, EAP extensions are defined to also support UE-initiated PDN requests and seamless inter-system handover requests.
For the case of multi-PDN capable TWAN 102 scenarios, a new WLAN Control Protocol (WLCP) has been defined between the UE and TWAN 102 to enable one or more UE PDN connection requests and seamless handover procedures. Note however, that a separate EAP procedure is still utilized between the UE and 3GPP AAA server 118 for UE authentication.
The Internet of Things (IoT) is the interconnection of uniquely identifiable objects within the existing Internet. IoT is envisioned to offer advanced connectivity of devices, systems, and services with many different protocols, domains, and applications.
Things or objects in the IoT include a large variety of devices such as heart monitoring implants, biochip transponders, automobile built-in sensors, temperature sensors, security monitors, and field operation devices. It's estimated that more than 30 billion devices will be wirelessly connected to the IoT (or Internet of Everything) by 2020, and that IoT or Cloud of Things, such as embedded and wearable devices, will have widespread and beneficial effects by 2025.
Directly connected to the Internet, most of the devices comprising IoT services will need to operate by utilizing standardized technologies. Standardization bodies, such as the IETF and ETSI, are working on developing protocols, systems, architectures and service frameworks to enable the IoT. A newly formed standard body oneM2M has been focusing on M2M/IoT service layer standardization for supporting End-to-End (E2E) M2M/IoT Services.
3GPP is designing a 5G network and is considering to incorporate the network slicing technology, which is a good fit for the 5G network. Because the 5G use cases (e.g., massive IoT, critical communications, and enhanced mobile broadband) demand very diverse and sometimes extreme requirements. The current architecture utilizes a relatively monolithic network and transport framework to accommodate a variety of services such as mobile traffic from smart phones, OTT content, feature phones, data cards, and embedded M2M devices. It is anticipated that the current architecture is not flexible and scalable enough to efficiently support a wider range of business need when each has its own specific set of performance, scalability and availability requirements. Furthermore, introduction of new network services should be made more efficient. Nevertheless, several use cases are anticipated to be active concurrently in the same operator network, thus requiring a high degree of flexibility and scalability of the 5G network.
Network slicing enables the operator to create networks customized to provide optimized solutions for different market scenarios which demands diverse requirements, e.g. in the areas of functionality, performance and isolation. However, there are some challenges and issues to support network slicing in the future 5G network:                How to achieve isolation/separation between network slice instances and which levels and types of isolation/separation will be required;        How and what type of resource and network function sharing can be used between network slice instances;        How to enable a UE to simultaneously obtain services from one or more specific network slice instances of one operator;        What is within 3GPP scope with regards to Network Slicing (e.g. network slice creation/composition, modification, deletion);        Which network functions may be included in a specific network slice instance, and which network functions are independent of network slices;        The procedure(s) for selection of a particular Network Slice for a UE;        How to support Network Slicing Roaming scenarios;        How to enable operators to use the network slicing concept to efficiently support multiple 3rd parties (e.g. enterprises, service providers, content providers, etc.) that require similar network characteristics.        
More details (i.e., issues, problems and possible solutions) could be found in 3GPP TR 23.799, Study on Architecture for Next Generation System about how 3GPP applies the network slicing in the 5G network architecture.
It should be appreciated that the ideas describes here may be implemented as part of 5G network, possibly as part of a network slice. Functions that are described as being executed by a node such as the MME or S-GW may be executed by a virtualized network function.